案: Piping Serverの送信者用毎行JSONログ - クエリパラメタで実現する
#Piping_Server
構想段階。
関連: 案: Piping Serverの送信者に送信結果がプログラム側から理解しやすいようにする案
リクエスト
$ curl -T - https://ppng.io/mypath?log_type=json
追記: log_format=も良いかも
ついでにログの出力を無しにすることもできる機能をつくる。（通信量の微量な削減）
$ curl -T - https://ppng.io/mypath?log_type=none
今まではfor_human（もっと良い名前に）の省略だったということにすることで互換性を保つ。
$ curl -T - https://ppng.io/mypath?log_type=for_human
log_type=englishやlog_type=enなども考えられるがこれだとjapaneseやjaなどの他言語対応をほのめかしそうで、できればPiping Serverを軽くシンプルに抑えAsciiの範囲で収めたい気持ちが今はあるので避けたい気持ち。
将来的にJSON以外にCBORなどのバイナリフォーマットをログの形式などにもできるため拡張性はあると思う。
クエリパラメタにする理由
HTTPヘッダにしない理由は独自のX-...になるのと、どんな環境でも設定したいのでクエリパラメタとHTTPヘッダを比較すればクエリパラメタの方が設定できる機会が多い為クエリパラメータになった。
クエリパラメタ名
log_typeにするかsender_log_typeにする検討しているが、受信者にログの機能がつくことはないはずなので
log_typeとする方に傾いている。
受信者も[ERROR] The number of receivers has reached limits.などのエラーログがありえる。
つまりsender_log_typeにはならなさそう。受信者と送信者で別々のsensor_log_typeやreceiver_log_typeなどと分ける方が避けたい。
ステータスコードとかぶるのもあるが失敗したときはステータスコードだと独自に拡張しない限りたくさんの種類に対応できないと思うし付加情報を入れたいときはJSONの方が柔軟だとおもう。
ログの形式
code:console
$ curl -T - https://ppng.io/mypath?log_type=json
{"log_version":1}
{"status":"wait_receivers","n_connected_receivers":0}
{"status":"connection_established","n_connected_receivers":1}
{"status":"finished"}
こんな感じなることを想定している。
1行ずつパース可能なJSONになっている。
最初はログのバージョンが表示される。(sensor_log_versionになる可能性もあるが少し長い)
最初のバージョン以外はすべて"status"フィールドを持っている。
typeぽいものに相当しているのでtypeやkindになるかもしれないが、今の所statusが一番しっくりくる。
フィールド名やその値などはざっくりした例であり、簡素でかつ矛盾や混同させない命名を探したい。